Skip to content

Conversation

hamzaremmal
Copy link
Member

@hamzaremmal hamzaremmal commented Sep 24, 2025

Superseed #24062

Steps to reproduce:

git clone git@github.com:scala/scala.git --single-branch --no-tags --branch 2.13.x embed
cd embed
git filter-repo --path src/library --path-rename src/library:library/src
git filter-repo --message-callback 'return re.sub(rb"(?<!\w)#(\d+)", rb"scala/scala#\1", message)'
git remote add scala3 git@github.com:scala/scala3.git
git fetch scala3
git replace --graft b594c22eac364ca2449a2700506b4f6b3f571b86 2308509d2651ee78e1122b5d61b798c984c96c4d
git filter-repo --proceed
git checkout -b stdlib-history
git checkout -b sync-24-09-2025 scala3/main
git merge stdlib-history # Also fix the two conflicts that occurred
git push scala3

som-snytt and others added 19 commits May 15, 2025 12:01
Comment on private ListBuffer.locate [ci: last-only]
…sage

Use List.fill instead of range [ci: last-only]
…array

IterableOnce#copyToArray uses helper for count [ci: last-only]
This fixes scala/scala#13108 when comparing Seq[Float] with Seq[Float] it expected
that Float.NaN != Float.NaN and 0.0 equals -0.0f. But before this patch
this was violated by ArraySeq.ofFloat/ofDouble
Fix ArraySeq.ofFloat/ofDouble.equals for floating point
Extract branches to be mostly dependent on `isInclusive` and
`step >= 0`. These are often constant, and when they're not
statically constant, they are probably predictable anyway.

This commit upstreams
scala-js/scala-js@a5337ed
from Scala.js.
Previously, `Range` used a number of intermediate operations on
`Long`s to avoid overflow. We can streamline a lot of code by
using unsigned `Int` arithmetics. In particular, there is only 1
division in the initialization path, instead of 3.

Although the fields have not changed, the content of
`numRangeElements` is more strict for overfull ranges. This means
that deserializing an overfull range from a previous version would
not be safe. This is why we bump the SerialVersionUID.

This commit upstreams
scala-js/scala-js@d972218
from Scala.js.
Avoid evaluating `value0` twice on completed Futures for performance.
perf: avoid double checking `value0` Future.
@hamzaremmal hamzaremmal marked this pull request as ready for review September 24, 2025 19:17
@hamzaremmal hamzaremmal requested a review from a team as a code owner September 24, 2025 19:17
@hamzaremmal hamzaremmal requested review from lrytz and sjrd September 24, 2025 19:21
@lrytz
Copy link
Member

lrytz commented Sep 25, 2025

Some merge commits show up (scala/scala#11059), but not all (scala/scala#11061, scala/scala#11098). 🤷‍♂️ I guess?

What is unfortunate here is that navigating the history of a change will become a lot more difficult. In a few years, if someone wonders about the history of e8534ef (for example), how would they find their way from there to discussion on scala/scala#11098?

Amending the commit messages to link to the original commit on scala/scala (scala/scala@bd6bdf8 in this case) would solve it. But I assume that ship has sailed for the library history that is already in scala/scala3 today?

@sjrd
Copy link
Member

sjrd commented Sep 25, 2025

Oh, that is unfortunate, indeed. I never thought about that.

But I assume that ship has sailed for the library history that is already in scala/scala3 today?

No ship has ever truly sailed in git land. But in this case, the cost of fixing it probably exceeds what any of us is willing to spend in git hackery. In particular it would mean rewriting the history of scala3/main since the first merge with new SHAs.

One mitigation would be to expose an external index of corresponding commits, that we could look up manually.

@hamzaremmal hamzaremmal merged commit a8d6cbf into main Sep 25, 2025
62 of 67 checks passed
@hamzaremmal hamzaremmal deleted the sync-24-09-2025 branch September 25, 2025 13:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants